次世代 Web カンファレンス ：パフォーマンス
ローディング
サーバープッシュ
サーバープッシュあんまり使われてない
パフォーマンス向上に役立ってるというデータも見られない
速くなるというよりは、「遅くならない」
ロードの深さは遅くなる
JavaScriptバンドル
サーバープッシュ活用するとツールが変わりそう
現場が変われるのか？
WebPackが使えないと高速化できない現場いいのか
キャッシュのアプローチ
Service Worker
プリフェッチ
どこまでやっていいのかは開発者の感覚に委ねられてる
次のページ結構取得しちゃうのも見るが、速度のためにデータ量そんな使っていいのか？
最たる例がAMP
Quick Link
* ビューポートに入ってきたリンクをプリフェッチするライブラリー
* 通信環境も見てはいるらしい
圧縮
3Dモデルの圧縮は難しい
ポリゴンのどの点とどの点が繋がっているのか、とかが難しい
CDNで圧縮するのかオリジンで圧縮するのがいいのか
最初CDNで全てやっていた
漏れがないから
考えることが減らせる
オリジンに対する通信量が多いとトラフィックがきになる
CSSをインライン化した場合通信量が増えた
CDN
レイテンシー
一番はキャッシュヒット
次にCDN
CDNによる最適化
どこまでレイジーロードで対応するか、初期に乗せる最初にロードさせるか
ATFの話
画面に収まる最適化は意味ない
スクロールするので
スクロール量があると、リソースの優先順位気にして置く必要がある
ランタイム
インタラクションまでの待ち時間
初期表示に不要な処理は後に回していく
スケジューリングをネイティブで入れていく議論もされている
カスタムエレメントを使うと、JavaScript処理が終わる前に内容自体は送れるのでいいのではないか SEO的によさそう
スタイルは、JavaScriptが評価されるまで適用されないのが・・・
しょうがない。遅い環境ではその方がいいことがあるだろう
レイアウトがガタガタになるのは気になる。ちらつきはいいと思う
3Gでのエミュレート
lighthouseとかで3Gでテストするが、どう思うか？（sisidovski）
開発者は普段速い環境に慣れているから、遅い環境でのテストは大事（1000ch）
3Gはユーザーの環境を代表していないのでは？（sisidovski）
改善したのが、本当にユーザー環境での速度改善になっているのか？
速度制限がある環境では、近い環境になっている（likr）
エンジニアの心構えとしてミニマムに合わせるのは大事だと思ってる（1000ch）
ビジネスの観点が入ってくるなら、リアルユーザーの環境を考える必要はあるだろう
モニタリング
lighthouse
点取りゲームとして使ってるがもっといいツールも欲しい（sisdovski）
Web Page Test
自前のツールでパフォーマンスとってサーバーに送って分析
指標は？
Speed Indexが一番見てる（sisidovski）
TFPとTTI
lighthouseだけ見てるとlighthouseに向けの最適化になってしまうのでは？（1000ch）
参考程度にしている。ネットワークタブをちゃんと見てる（sisidovski）
パフォーマンスは職人技。パフォーマンスタブを眺めてもどうなっているのか、どうしたらいいのか難しい（likr）
メトリクスを知るところから（1000ch）
前よりは数値にできるようになってる。最近できるようになった（sisidovski）
とりあえずこのフレームワークニノっとけばパフォーマンスが出る、とかもある（likr）
AMPとかGatsbyとか
バーチャルDOMは色々解決した（1000ch）
特にランタイムパフォーマンス
やっぱりDOMが重い
Web Packagingは広まっていきそう（sisidovski）
ランタイムというよりはローディングだが
色んなCDNに、オリジンと同じであることが保証されたコンテンツが乗る
AMPのURL違う問題も解決（1000ch）
SIMD
必要な計算が結構ある（likr）
数値計算
他に必要なケースはない（1000ch）
ウェブのパフォーマンスが必要なのは二つある（likr）
一つは快適になること
一つはこれまでできなかった複雑な計算ができるようになること
WASMやSIMDで100倍速くなると、できるようになることがある
ネイティブアプリとのギャップをどう埋めるかというのもアプローチできる
パラダイムを変える研究はしてる？（1000ch）
可視化は絵を出すだけじゃなくて、対話的に操作して分析を深める必要がある。（likr）
これに、100倍速くなることは寄与する
など、デスクトップアプリではできたがウェブではできなかったことがある（likr）
ウェブだと配布しやすいのでそこはデスクトップアプリより優れてる（likr）
ウェブはマルチスレッドが難しいが、WASMに閉じた中ではマルチスレッドやりやすい（likr）
並列化
ウェブワーカー注目されてる（1000ch）
オフザメインスレッドで。
Comlinkとか。
ワーカー内でやり取りする構文も策定されてる
worker-domに注目してる（sisidovski）
お絵かきアプリでmousemoveで座標を取ると、ブラウザーによってずれることがある。これの処理をワーカーに移したらうまくいったという経験がある
worker-domはライブラリーだが、本当にワーカーから直接DOMを触れる仕様は策定されてる？（1000ch）
進んでない（azu）
Angularで、ワーカーでDOMツリーを構築して、実際のレンダリングをメインスレッドでやってるのを見たことがある（likr）
注目してるAPI
WASM（likr）
仕様としてまだ進めていくべきことはある
スレッドとか
開発ワークフロー（コンパイル元の言語）の整備が進んでない
WASMの計算に時間がかかる場合、ワーカーと組み合わせる必要がある。Comlinkとかあるが今後も発展が必要
Taskワークレットとかどうなった？
ケイパビリティ（sisidovski）
ネイティブアプリのように動くためのAPI
フィーチャーポリシー
サードパーティスクリプトにdocument.writeさせない、とかを宣言的にかける
これがうまくいけばウェブがもっと速くなるはず
ユーザータイミングを取るAPI（1000ch）
Frame Timing, Element TimingとかSpeed Indexで取るライブラリーがあるが、それに時間がかかってしまう
これがAPIになってほしい
Long Tasks API（1000ch）
長いタスクを見つけられるやつ。これをGAとかに投げると分析できる
HTTP/3は？
HTTP2はCDNの人にお任せ状態だが、 HTTP/3もそうなるだろう（sisidovski）
同意（likr）
ラウンドトリップ以外に（パフォーマンスに）どういうメリットがあるのか分からない
画像の圧縮
やりたくないという意味で嫌い（likr）
パフォーマンスを出す上では必要だとは思うが
GIFアニメーションは思いが動画だと軽くなるはずだが（1000ch）
JPEGに色々ある
アルゴリズムに足を踏み入れることがフロントエンドにいるとない（sisidovski）
全部SaaSに投げるようになってる
パフォーマンスのボトルネックが画像にあることが多い（1000ch）
最初に表示するときに何が重いのかはモニタリングしてはいる（sisidovski）
ロード中に先にやるべき処理、やらないべき処理
サードパーティ系の処理を後ろに回す（sisidovski）
SSRの人は分からないが
ユーザーのインタラクションと見た目の表示に必要な物を重視（sisidovski）
コンテンツの更新時間（「n分前に投稿」）は見た目に関わるので大事だと思ってる